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Crear regimientos para 


Aunque se suponía que en el número 9 de 
Rendermanía ¡iba a tener lugar la tan 
prometida batalla entre orcos y humanos, al 
final ésta quedó reducida a una misérrima 
escaramuza entre zombis y humanos. La 
sustitución de los orcos por los zombis se 
debió a que por entonces no disponíamos de 
ningún modelo decente de orco, detalle este 
que ya fue subsanado en el número 11. Más 
grave fue, sin embargo, el problema del brutal 
consumo de memoria que «POV» parecía 
requerir para representar escenas con cientos 
de modelos (y que redujo la “batalla” a sólo 


tres pares de luchadores). Pero, aunque 


parezca increíble, este problema se debía tan 


sólo a la ignorancia y no a una limitación de 


«POV». Sabed.pues, oh Rendermaníacos y - 
Povadictos... ¡Que Mesh nos permitirá crear 
primorosas escenas compuestas por cientos 


de modelos complejos! 


ÍA José Manuel Muñoz 


ntes de empezar, claro 


está. debemos pedir 
disculpas a los lectores 
por no haber hablado 
antes de esta importan- 
tísima sentencia del 
lenguaje escenico de «POV». Hace bastan- 
te tiempo. cuando empezamos a leer el 
dociorial de «POV», pasamos rápidamente 
por Mesh y nos centramos sobre todo en 
las sentencias de programación, pensando 
erróneamente que Mesh sería una optimi- 
zación sin importancia. Solamente hace 


unos meses. al preparar el especial so- 


bre «Rhinoceros», comprendimos el 
enorme potencial de esta sentencia 
gracias a que «Rhino» empleaba Mesh 
para exportar sus escenas al formato de 
«POV». Intrigados por ello estudiamos 
esta instrucción con algo más de aten- 
ción y... bueno, ahora veréis. Nuestra 
única disculpa posible —aunque pobre 
es que nadie más parece haber dado a 
Mesh el valor que merece: al menos 
nosotros no hemos encontrado aún una 
sola escena —ni en la red ni en el foro- 


en la que se haya 
empleado a Mesh 
para crear fantás- 
ticas escenas con 
cientos de mode- 
los. ¿Por qué? En 
fin, puede ser que 
no hayamos bus- 
cado lo suficiente. 
Si este es el caso 
esperamos que al- 
gún amable ren- 
dermaníaco nos 
saque del error... 
También quere- 
mos añadir que en 
este artículo he- 
mos supuesto que 
el lector compren- 
de el funciona- 
miento de +if, 
twhile y de otras 
“sentencias de 
programación” ya 
explicadas hace 
mucho y sobre 
cuya importancia no nos cansaremos 
de insistir. 


Exportación de modelos a 
«POV» 

Como ya saben los usuarios experi- 
mentados de «POV», nuestro raytracer 
dispone, desde hace mucho, de un par de 
sentencias —triangle y smooth_triangle— 
que le permiten usar objetos construidos 
desde modeladores poligonales como 
«Imagine» o «3D Studio». Para ello ha 
de seguirse el siguiente proceso: 


1) El usuario crea su modelo em- 
pleando su modelador preferido («3D 
Studio», «Imagine», «trueSpace». etc.). 
Con ello obtendrá un modelo que no 
será directamente digerible por «POV» 
(la excepción está en el uso de algún 
modelador como «Moray». expresa- 
mente creado para «POV», y de otros 
programas del mismo tipo). En efecto: 
normalmente el modelador guardará la 
malla de triángulos que forma al mode- 
lo como un fichero binario empleando 
un formato propio ininteligible para 
«POV» (3DS en el caso de «3D Stu- 
dio», obj en el de «Imagine». etc.). 
Aunque también es frecuente que estos 
modeladores ofrezcan además la op- 
ción de guardar el modelo usando el 
formato DXF o bien un formato ASCH 
sencillo, a fin de facilitar las exporta- 
ciones de objetos a otros programas. 

2) Seguidamente, el usuario debe- 
rá emplear alguna herramienta de con- 
versión para “traducir” el archivo ge- 
nerado por el modelador (en números 
anteriores ya hemos hablado de algu- 
nas de estas herramientas: 3ds2pov. 
3dto3d, Wevt2pov, etc.). El resultado 
será un nuevo fichero en formato AS- 
CH y comprensible para «POV>» en el 
que los polígonos del modelo del ar- 
chivo suministrado como entrada serán 
traducidos a sentencias triangle y smo- 
oth triangle. Estas sentencias fueron 
implementadas en el lenguaje escénico 
de «POV» por el Povteam pensando 
precisamente en el caso de aquellos 
usuarios que deseasen emplear mode- 
los no creados desde el mismo «POV». 


Teóricamente podrían ser empleadas 
por el usuario para crear objetos a ma- 
no, empleando un procesador de tex- 
tos, pero esto, a menos que el objeto 
sea algo tan sencillo como un cubo, no 
resulta práctico. ya que habría que cal- 
cular a ojo un montón de coordenadas 
de vértices. 

3) Después, simplemente, habre- 
mos de incluir el archivo .POV o .INC 
resultante de la “traducción” en nues- 
tro fichero escénico. Para ello escribi- 
remos una o más órdenes HHinclude en 
el archivo donde se describe nuestra es- 
cena. Esto no siempre será necesario ya 
que puede ocurrir que todos los ele- 
mentos de la escena ya hayan sido es- 
tablecidos desde el modelador y que no 
deseemos cambiarlos desde «POV». 
En estos casos las utilidades como 
3ds2pov nos vendrán de perlas, ya que 
generan archivos .POV en los que se 
“traduce”, además de a la malla con el 
modelo, a las luces, la colocación y 
orientación de la cámara, los colores de 
los objetos y sus propiedades de super- 
ficie, etc. De esta manera bastará con 
invocar a «POV» y pedirle que renderi- 
ce el archivo .POV generado por la he- 
rramienta de traducción. Así obtendre- 
mos una imagen muy similar a la que 
podríamos renderizar desde el modela- 
dor que hayamos usado. 

Para mayor comodidad del usuario, 
las mejores utilidades de conversión 
(como 3ds2pov) generan 2 o más archi- 
vos para «POV». Suelen crear un fiche- 
ro .POV en el que se incluye la “traduc- 
ción” de la cámara y las fuentes de luz, 
y uno o más archivos .INC donde irán 
las sentencias triangle y smooth_trian- 
gle con la forma del modelo. Para nues- 
tros propósitos actuales, o sea para ge- 


CómI0... 


nerar escenas complejas con cientos de 
modelos, lo mejor será colocar cada uno 
de estos modelos en la escena aprove- 
chando las magníficas capacidades del 
lenguaje escénico de «POV». Por ello 


prescindiremos de los ficheros .POV ge- 
nerados en las conversiones, quedándo- 
nos únicamente con los archivos que 
describen la geometría de los modelos. 

Sabido esto ya sólo nos queda recor- 
dar algunos de los problemas que fasti- 
diaron a nuestra batallita. Uno de ellos 
es que los objetos creados con modela- 
dores poligonales se almacenan como 
mallas de caras compuestas por vérti- 
ces, requiriendo cada uno de los cuales 
¿tres valores en flotante para describir 
¿su posición espacial (y aún puede ser 
necesaria más memoria para describir 
los vectores de las normales, si éstas 
son también almacenadas). Esto quiere 
decir que frecuentemente los archivos 
¿ .INC que habremos de manejar serán 
d muy grandes, con lo cual «POV>» preci- 


Un experimento cambiando el 
tamaño de la formación y las 
relaciones de proporción de los 
modelos. 


Un plano más cercano a los guerreros. 


sará mucha memoria para incluirlos en 
nuestras escenas. Sin embargo, lo peor 
es que, para cada copia del modelo em- 
pleada en la escena, «POV>» requerirá 
(usando union) la misma cantidad de 
memoria. Así, si por ejemplo, un orco 
requiere 6 Megas de RAM, la inclusión 
de 6 monstruos de este tipo en una es- 
cena precisará 36 Megas. Este proble- 
ma fue el mayor obstáculo para la tan 
ansiada batalla orco-humana, 


Mesh: un milagro bien 
sencillo 
: Este problema de la excesiva deman- 
. da de memoria se debe al empleo de la 
¿sentencia union, Las utilidades de con- 
¿ versión algo antiguas como 3ds2pov y 
E 3dto3d usan esta sentencia para englo- 


bara las sentencias triangle y smooth_trian- 


gle que describen a los modelos importa- 
dos. Como recordarérs, union se usa para 
indicar a «POV>» que un conjunto de obje- 
tos individuales (en este caso un conjunto 
de triángulos) forman un único objeto. An- 
tes de la versión 3.0, el uso de union pa- 
ra los objetos importados resultaba im- 
prescindible ya que de esta manera 
bastaba con especificar una única textu- 
ra que se aplicaba sobre un grupo de 
triángulos (en vez de hacer lo propio pa- 
ra cada triángulo). Además, usando esta 
sentencia podíamos colocar sentencias 
de transformación que afectaban a todo 
el grupo de triángulos englobados por la 
unión. Sin embargo, union no fue crea- 
da para agrupar triángulos, sino objetos 
creados desde el propio «POV». La 
sentencia mesh, en cambio, sí ha sido 
diseñada exclusivamente con esta fina- 
lidad y funciona exactamente igual que 
union. La única diferencia radica en que 
con mesh los grupos de triángulos en- 
globados se almacenan en memoria una 
única vez. Así, en la siguiente ocasión 
en que invoquemos al objeto-mesh den- 
tro del fichero de escena, «POV» única- 
mente precisará una pequeña cantidad 
de RAM para generar al objeto, el cual 
será considerado como una copia del 
primero. Únicamente hay que recordar 
que mesh sólo podrá ser usada para en- 
globar triángulos (si usamos una senten- 


cia mesh para englobar a varias mesh o 
para englobar a objetos normales, el par- 
ser nos dará el error “No triangles in 
triangle mesh”). 

Dado que las utilidades como 3ds2pov 
o 3dto3d no generan aún ficheros con 
mesh sino con union (al menos en las 
versiones más modernas que hemos po- 
dido encontrar), deberemos —si usamos 
estas herramientas y queremos aprove- 
char la potencia de mesh— emplear un 
editor de textos para sustituir las senten- 
cias union por mesh. Otros programas 
más modernos como «3Dwin 3.0» de 
Thomas Baier (que hemos incluido en 
el CD) sí generan conversiones mesh. 

Seguidamente comentaremos la for- 
ma más adecuada de usar mesh y estu- 
diaremos la lista de experimentos que 
llevamos a cabo para usar mesh con 
modelos antropomórficos y que de- 
sembocó en las diversas escenas que 
ilustran este número. 


Creando nuestro primer 
regimiento de orcos 

El modelo de orco empleado para 
crear las escenas básicas de nuestro re- 
gimiento de ejemplo es el que presenta- 
mos en el número 11 de Rendermanía. 
La cabeza de este orco fue creada con 
«Rhinoceros», el cual sí hace exporta- 
ciones con mesh, por lo que no fue de- 
masiado difícil preparar a la menciona- 
da cabeza para usarla en los primeros 
experimentos hechos para comprobar 
el funcionamiento de esta 
sentencia. Lo mismo ca- 
be decir del cuerpo, el 
cual está basado en una 
malla que hallamos por la 
Red. La cabeza original 
de dicha malla fue elimi- 


nada y las proporciones del cuerpo alte- 
radas desde «Rhino» para adecuarlas a 
las formas exageradas y monstruosas de 
los orcos. En cuanto al faldellín y a las 
armas se hicieron también en «Rhino» 
o se importaron de «Imagine». Por últi- 
mo. el modelo completo se exportó a 
«POV>» en varios archivos; uno para la 
cabeza, otro para el cuerpo y otro para 
las armas... (al menos así fue en las pri- 
meras pruebas). 

Ahora veamos la forma más sencilla 
de emplear Mesh. Después de utilizar 
una herramienta de conversión lo más 
probable será que vbtengamos uno o mas 
archivos .INC, cada uno de los cuales es- 
tará formado por varias sentencias union 
o mesh (dependiendo de si la herramien- 
ta usada es un poco antigua O no). Lue- 
go, para cada fichero, sustituiremos =sl 
las hay— a las sentencias union que en- 
globen a los triángulos por instruccio- 
nes mesh. También deberemos elimi- 
nar, si las hubiera, las definiciones de la 
cámara y de las fuentes de luz. (En el 
caso de 3ds2pov, todo esto se pone 
aparte pero no todas las utilidades de 
conversión funcionan igual). Por últi- 
mo, y en caso de que no la hubiera, de- 
beremos crear una union que englobe a 
todas las mesh del fichero .INC sobre 
el que estemos trabajando. Este último 
paso será imprescindible para referen- 
ciar luego a las mallas desde el fichero 
de escena con sentencias como las que 


podéis ver en el cuadro 1. 


Así, cuando «POV» esté compilando 
la escena, al encontrar el include, el 
programa ¡rá cargando el archivo y pa- 
sando los datos de las mallas a la 
RAM. Más tarde. el modelo podrá ser 
invocado cuantas veces deseemos 
usando sentencias object y «POV» tan 
solo precisará una pequeña cantidad de 
memoria para los datos propios de cada 
referencia al objeto inicial. Ni que decir 
tiene que sería una estupidez usar sen- 
tencias COMO... 


objectístinclude “body1.inc”] 
...cada vez que deseásernos crear un nue- 
vo modelo en la escena, ya que entonces 
«POV>» cargaría nuevamente el archivo 
cada vez que hallara una de estas senten- 
cias en el fichero de escena. Examinad 
el listado de la siguiente figura. 


“Ejemplo de creación de un cuadro de 
guerreros orcos” 


Htdeclare orco1=objectí*tinclude “orco.inc”] 
tideclare nfilas=8 
Htdeclare xpos=0 
ttdeclare zpos=0 
fiwhile(colum!=0) 
Htdectare xpos=0 
ftdeclare fila=8 
Fwhile(fila!=0) 
objectíorco1 translate <xpos,0,zpos> ) 
Htdeclare xpos=xpos+120 
Hideclare fila=fila-1 
end 
Htdeclare zpos=zpos+120 
Hideclare nfilas=nfilas-1 
end 


Este ejemplo corresponde a una de 
las primeras pruebas con mesh (cuando 
el orco aún no había sido dividido en 
piezas) y en él se crea a un cuadro de 
8x8 guerreros orcos. En esta y en las si- 
guientes pruebas las “sentencias de 
programación” fueron imprescindibles 
para crear grandes grupos de guerreros. 


Estadísticas 

Para hacernos una idea 
cabal de lo conveniente 
que es el uso de mesh vale 
la pena citar algunas esta- 
dísticas recogidas tras las 
primeras pruebas con esta 
sentencia. Las mallas del 
orco completo tienen mu- 
chos triángulos y por ello, 
tras realizar el primerren- 
der para una sola de estas 
eriaturillas, pudimos ver 
en la pantalla de estadísti- 
cas la nada desdeñable ci- 
fra de 14.612.203 bytes. 
¡Casi 14 Megas de RAM 
para un solo orco! Sinem- 
bargo. al añadir 63 orcos 
más a la escena, el gasto 
de memoria tan sólo as- 


El primer cuadro de orcos. 


Lo mismo haciendo variaciones de tamano. 


cendió a unos 2 Megas 
más. Por otro lado, para 
otros modelos menos 
complejos como el del 
lancero, el gasto de me- 
moria fue aún menor. Á 
priori resulta imposible 
predecir la cantidad total 
de memoria que precisare- 
mos para crear un grupo 
de objetos-copia (así los 
llamaremos desde ahora). 
Sólo podemos estar segu- 
ros de una cosa, el ahorro 
de memoria será impresionante y además 
podremos manipular a los objetos-copia 
de maneras sumamente interesantes. 


Perfeccionando el regimiento 
de orcos 

En la primera prueba se creó una 
formación cuadrada de 8x8 orcos. Este 
cuadro de guerreros no resultaba de- 


y 


Añadiendo pigmentación aleatoria, cabezas 
adicionales, más armas y descolocación 
aleatoria. 


masiado atractivo y el mayor problema 
fue. por supuesto, que todos los orcos 
eran iguales. Este problema sólo tenía 
una solución posible: crear más orcos. 
Pero claro, cada nuevo monstruo hu- 
biera requerido (de emplear la misma 
densidad poligonal y detalle que en el 
primero) otros 12 6 13 Megas de me- 
moria. Además, esto sólo nos hubiera 


dado una va- 
riación de 2 
tipos de per- 
sonajes dife- 
rentes dentro 
del cuadro de 
64 orcos, con 
lo cual no hu- 
biéramos 
conseguido 
gran cosa. Fi- 
nalmente, se 
tomaron las siguientes medidas para me- 
jorar el resultado inicial: 

1 Se desglosó el modelo comple- 
to del orco en varias partes: el cuerpo, 
la cabeza y las armas. Luego se alteró 
el código del fichero escénico de ma- 
nera que según un factor aleatorio se 
colocase la cabeza creada en el núme- 
ro 11 o las diseñadas en el 13 con 
Spatch. Además se hizo lo mismo con 
las armas y el estandarte (como estos 
objetos se empuñan de la misma ma- 
nera y están colocados en la misma po- 
sición espacial son fácilmente inter- 
cambiables). 

2) Los objetos componentes del 
orco se englobaron dentro de una 
union, de manera que pudieran variarse 
las proporciones globales de altura y 
anchura de cada personaje. 

3) Como la alineación del cuadro 
de guerreros resultaba excesivamente 
perfecta, se introdujeron pequeñas al- 
teraciones aleatorias de posición en ca- 
da orco. 

4) Se introdujo un pequeño factor 
aleatorio de rotación lateral en la cabe- 
za de cada personaje. 

5) Se alteraron los ficheros -INC 
para que el color básico de la piel de 
cada orco sufriese pequeñas variacio- 
nes aleatorias. 


Resultado final añadiendo un 
portaestandarte. 


El resultado final —visible en la es- 
cena final de la serie de pruebas—, aun- 
que aún dista bastante de la perfección, 
es muy superior al obtenido en la pri- 
mera imagen de la misma. Sin embar- 
go. lo importante es comprender que 
cada uno de los modelos que aparecen 
en la escena final de la serie ha ocupa- 
do —a pesar de sus leves variaciones 
con respecto al modelo original— tan 
solo una pequeña cantidad de memo- 
ria. Viendo esto uno no puede por me- 
nos de preguntarse si no será posible 
conseguir un resultado aún mejor, y lo 
cierto es que sí que es posible. En el si- 
guiente artículo explicaremos cómo es- 
to puede lograrse siguiendo un curioso 
y sencillo método. Por ahora echare- 
mos un vistazo en detalle a los trucos 
que se han empleado para la última es- 
cena de la serie. 


Trucos de programación 

Las llamadas “sentencias de progra- 
mación” del lenguaje escénico de 
«POV» son vitales para crear escenas 
con cientos o miles de modelos. Por 
ejemplo para crear el cuadro de guerre- 
ros se empleó un bucle anidado dentro 
de otro. El bucle más interno crea los 
guerreros de cada fila y usa para ello el 
contador fila. El bucle más exterior se 


encarga 
—usando 
el contador 
nfilas— 
de contro- 
lar el nú- 
mero de 
filas que 
tendrá la 
forma- 
ción. Así, 
por ejem- 
plo, unos valores de 4 y 10 para nfila y 
fila respectivamente crearían una for- 
mación de 4 filas de profundidad con 
10 guerreros en cada fila. Pero, por su- 
puesto, podríamos haber dado valores 
para crear un cuadro de 400 o más or- 
cos. ¿Os imagináis situándolos en la 
escena a mano? (Gracias al povteam 
por Htwhile). 

Pero sigamos: el guerrero “origimal” 
(el cargado en memoria con +tinclude) 
está centrado en los ejes X y Z y tiene 
los pies sobre Y=0. Así que, para des- 
plazar cada objeto-copia a la posición 
adecuada dentro de la formación, po- 
demos usar una sentencia parecida a 
esta 


objectíorcol translate <xpos,0,zpos> ) 


Naturalmente dentro del bucle inter- 
no la variable xpos se irá actualizando 
en cada pasada del mismo con una sen- 
tencia como... 


Hdeclare xpos=xpos+120 


donde el valor sumado a Xpos es la 
separación espacial en el eje X que el 
próximo orco tendrá con respecto al úl- 
timo creado en la escena (cuanto más 
pequeña sea la suma para Xpos y Zpos, 
más apretados estarán los guerreros 
dentro de la formación). 


Lo malo de esto es que la formación 
resultante es excesivamente perfecta. 
Conseguiremos un resultado más real 
si los guerreros se salen levemente de 
la posición ideal de cada uno. Para con- 
seguir esto lo mejor será emplear la 
sentencia rand para añadir una suma 
aleatoria a los valores de xpos e zpos. 
Echad un vistazo al código de la si- 
guiente figura. 


“Ejemplo tomado del fichero de generación de una de las 


escenas de la serie” 


Htdeclare cuerpo 1=object[H*include “body1.inc”) 
ftdeclare cabeza1=object(*+tinclude “head1.inc”) 
ftdeclare cabeza2=object[(Hinclude “head2.inc”) 
Htdeclare cabeza3=object(F*include “head3.inc”) 


declare R=seed(8534) 
Hdeclare colum=1 
declare xpos=0 
Hdeclare zpos=0 
Fwhile(colum!=0) 
Fdeclare xpos=0 
Fdeclare fila=8 
ftwhile(fila!=0) 
union(í 
objectícuerpo1) 
fídeclare a=int(rand(R)*3) 
ftswitch (a) 
Ficase (0) 


objectícabezal rotate <0,-25 +(rand(R)*50),0>) 


fíbreak 
Hcase (1) 


objectícabeza2 rotate <0.-25 +(rand(R)*50),0>) 


ffbreak 
ficase (2) 


objectícabeza3 rotate <0,-25 +(rand(R)*50),0>) 


ttend 

Hdeclare alto=.8 + rand(R)*.15 
ttdeclare ancho=.90 + rand(R)*.2 
scale <1*ancho, 1*alto, 1*ancho> 
fídeclare sumx=-15 +(rand(R)*30) 
Hideclare sumz=-15 +(rand(R)*30) 


translate <xpos+sumx,0,zpos+sumz> 


? 
declare xpos=xpos+120 
Hdeclare fila=fila-1 
end 
Hideclare zpos=zpos+120 
Hideclare colum=colum-1 
HHend 


Cóom20... 


En este ejemplo puede verse cómo 
se añaden a xpos y zpos los valores 
sumXx y sumz respectivamente. Estos 
valores representan una variación ale- 
atoria de 30 unidades con respecto a 
la posición ideal. Para lograrla se res- 
tan 15 unidades a dicha posición y se 
suma el valor aleatorio devuelto por 
rand. Como recordaré1s rand devuelve 
un valor aleatorio entre O y 1 por lo 
que multiplicar el 
valor devuelto 
por 30 equivale a 
obtener un valor 
aleatorio entre O 
y 30. Como se 
resta 15 al valor 
de estas varia- 
bles, el resultado 
es que cada orco 
puede ser coloca- 
do dentro de un 
rectángulo espa- 
cial de 30x30 
unidades cuyo 
centro es su post- 
ción ideal. Lógi- 
camente. si cam- 
biamos el valor 
de la semilla dado 
aR (en “declare 
R=seed(8534)”), 
el “desorden” ob- 
tenido en la for- 
mación será dife- 
rente, 

Otro detalle a te- 
ner en cuenta es 
que podemos va- 
riar la escala de 
un objeto-copia, 
diferenciándolo 
así un poco del 
modelo original. 


Esta posibilidad ha sido usada para al- 
terar la altura y el grosor de los orcos, 
logrando así orcos bajos y anchos y 
otros altos y delgados. Esto se ha con- 
seguido ordenando la siguiente trans- 
formación para la union del modelo 
completo: 


Hdeclare alto=.8 + rano(R)*.15 
Hdeclare ancho=.90 + rand(R)*.2 
scale <1*ancho,1*alto,1*ancho> 


Si exageramos los valores dados a 
alto y ancho obtendremos una varie- 
dad de proporciones aún mayor aun- 
que, por supuesto, seguimos sin po- 
der alterar las formas básicas del 
modelo. Por eso, el resultado es un 
cuadro de guerreros Orcos que pare- 
cen todos miembros de un clan fuer- 
temente endogámico. 

Y ya solamente nos queda dar cuen- 
ta de dos detalles. Como véis en el 
ejemplo de la figura, se escoge entre 
una y otra cabeza dependiendo (otra 
vez) de un valor aleatorio. En caso de 
que hubiéramos podido disponer de 
más cabezas hubiera sido sencillo am- 
pliar el switch para incluirlas así como 
variar la sentencia que asigna su valor a 
“a” (nótese el uso de int para forzar a 
«POV>» a devolver sólo valores enteros 
para el switch). 

En cuanto a la pigmentación tam- 
bién se ha usado un valor aleatorio pa- 
ra alterar un poco la intensidad del 
verde con respecto al color ideal de 
cada orco. Lo mismo se ha hecho con 
el color de la faldita y de la cota de 
mallas. Sobre esto último hay que de- 
cir que realmente no hay cota de ma- 
llas, sino tan solo un color distinto al 
verde de la piel, pero desde lejos po- 
demos dar el pego con un simple cam- 
bio de color. 


pa es 
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Creación de modelos-copia 
diferentes al modelo original 


En las páginas precedentes hemos visto cómo puede emplearse la 
sentencia mesh para crear copias de modelos en «POV». Como dichas 
copias requieren tan sólo una pequeña cantidad de memoria —en contraste 


con la gran cantidad de RAM que puede requerir el modelo original-, esto 


6 Ñ quiere decir que 

¿ podremos crear 
escenas con 
cientos o miles de 
formas complejas. 
Sin embargo, esto 
no es todo lo que 
podemos hacer: 


existe una manera 


sencilla de crear 


modelos-copia y darles posturas diferentes a la original. Es decir, si 
tenemos el tiempo suficiente, podemos crear docenas de posturas de un 
modelo para una escena y emplearlas sin que cada nueva postura precise 


más espacio del que requeriría un objeto-copia idéntico al modelo original. 
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ntes de empezar 
conviene aclarar 
que nuestro orco no 
es el modelo más 
adecuado para ilus- 
trar la técnica que 
vamos a describir en el presente artícu- 
lo. Ello se debe a que el cuerpo del mo- 
delo carece de objetos que sirvan como 
ejes de articulación. Por esta razón. en 
muchas de las posturas pueden apre- 
ciarse huecos en las rodillas, los codos 
o los hombros, con lo que queda de 
manifiesto que el cuerpo del orco no es 
un modelo sólido sino tan solo un con- 
junto de formas huecas. Este 
problema ha quedado sin so- 
lución por ahora, ya que no 
había tiempo para construir 
las formas necesarias e ncor- 
porarlas.al modelo (bueno, lo 
cierto es que hemos añadido 
unas esferas en las rodillas ya 
que los huecos que aparecían 
eran demasiado reveladores. 
pero esto no pasa de ser un 
apaño provisional). 

Sin embargo, lo realmente 
importante para nuestros pro- 
pósitos era demostrar la vali- 
dez del método que vamos a 
presentar a continuación, y 
para esto el orco resultaba 
mucho más conveniente que, 
por ejemplo, un mech. 


La idea básica 

En el artículo anterior las 
últimas escenas fueron crea- 
das dividiendo el modelo de 
orco en tres partes: el cuerpo 
completo, las cabezas y las 
armas. De esta manera, cada 
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mente intercambiable, lo cual daba al- 
gu de variedad a las escenas ¡¡lástima 
no haber tenido tiempo suficiente para 
preparar más cuerpos!! 

Hecho esto, nos preguntamos si no 
sería aún mejor almacenar cada parte 
del cuerpo separadamente, a fin de po- 
der aplicar cambios individuales en ca- 
da pieza. ¿ Y qué tipo de cambios? Pues 
no. evidentemente. cambios anatómi- 
cos, puesto que entonces ls proporcio- 
nes del modelo habrían quedado estro- 
peadas, pero sí cambios de orientación 
y de colocación. Asf, como cada parte 
estaría almacenada usando mesh y co- 


una de estas partes era fácil- 
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Preparando posturas para el orco. 


mo cada objeto-copia podría ser trans- 
formado independientemente, el resul- 
tado sería que podríamos crear orcos- 
copia con posturas diferentes a la del 
conjunto de piezas del orco original. 

El que esto funcione bien o no de- 
penderá, como en el caso del artículo 
anterior, de que estemos empleando 
una herramienta de traducción que res- 
pete la colocación que tenían los obje- 
tos en el espacio virtual del modelador 
donde fueron creados. Decimos esto 
porque hay algunos traductores 3D que 
olvidan dicha colocación y que además 
reescalan los objetos a su capricho al 
hacer la “traducción”, con lo 
cual no nos servirán para na- 
da. En el caso del orco, este 
fue modificado con «Rhino- 
ceros». programa desde el 
cual se exportaron todos los 
objetos al formato de «POV». 
Luego se comprobé, al crear 
una escena de prueba desde 
«POV», que «Rhino» había 
respetado la escala, coloca- 
ción y orientación de cada 
pieza al hacer la grabación, 
por lo cual el resultado fuen 
orco completo. 

Ahora bien; ¿cómo crear las 
posturas? Como imaginaréis, 
crear cada postura desde 
«POV» estableciendo los va- 
lores de rotación de cada ob- 
jeto es algo Trouy trabajoso (al: 
menos al principio, hasta que 
se acaba cogiendo práctica. 
Recordad que algunos esfor- 
zados rendermaníacos lo han 
hecho. Este es el caso de 
Óscar Alvárez Díaz, con su 
soldado imperial de asalto, y 
de Carlos Monterde Escude- 


ro, con su horda orca). Por es- 
ta razón, y después de expri- 
mirse un rato las neuronas, el 
autor de estas líneas ideó el 
siguiente método para crear 
cada nueva postura: 


1) «Imagine» es el pro- 
grama donde más fácil y rá- 
pidamente podemos crear 
nuevas posturas de un modelo antropo- 
mórfico. Para aprovecharnos de esta 
útil característica de «Imagine» carga- 
remos desde este programa el modelo 
Cuyas posturas desee 

Para ello deberemos grabar el mode- 


: Crear. 


lo desde el modelador que estemos em- 
pleando y traducirlo luego a un forma- 
to que pueda ser leído desde «Imagine» 
(al suyo propio o al DXF). Otra posi- 
bilidad es, simplemente, emplear un 
modelo antropomórfico similar al del 
orco ya que lo que nos interesa es Úni- 
camente tomar nota de los ángulos de 
rotación de las distintas partes del cuer- 
po. Esto último fue lo que se hizo (para 
evitarnos el trabajo de la conversión a 
«Imagine») y.empleamos para esto al 
modelo del no-muerto que apareció en 
Rendermanía número 9, usando la 
postura básica del mismo que es igual 
a la básica del orco (o sea, de pie y en 
postura de firmes salvo por las manos 
cerradas en puños). Esto sólo tiene un 
inconveniente: puede darse el caso que 
tengamos que hacer ajustes desde 
«POV» dadas las posibles diferencias 
entre el modelo antropomórfico em- 
pleado en «Imagine» y el modelo usa- 
do en «POV». 

2) Desde «Rhinoceros» o «Imagl- 
ne», o desde el programa que hayamos 
empleado para crear nuestro modelo, 
tomaremos nota de la posición de cada 


El ejército orco en formación de batalla. 


eje local de giro. Llamaremos eje local 
al punto espacial donde pivota una pie- 
za corporal o un conjunto de piezas. 
Por ejemplo, habrá que definir un eje 
local para la mano (situándolo en la 
muñeca), otro para el antebrazo (si- 
tuándolo a la altura del centro del codo) 
y otro para el brazo completo (situán- 
dolo en el centro del hombro). Así pues 
tomaremos nota de los valores <x,y,z> 
de la posición de cada eje local. Aten- 
ción: si establecemos mal la posición de 
estos ejes, luego desde «POV» pueden 
sucedernos cosas tales como que un 
brazo.o una pierna se salgan del cuer- 
po, al intentar definir su posición. 

3) Hecho esto crearemos las jerar- 
quías del modelo -si es que no estaban 
ya creadas— y procederemos a crear la 
postura deseada tomando nota del va- 
lor del ángulo para cada pieza y del eje 
en que dicha rotación va a llevarse a 
cabo. Aquí, naturalmente, lo mejor 
será que nos hayamos molestado en 
disponer previamente al modelo con 
una orientación tal que los ejes de ro- 
tación correspondan a la que normal- 
mente tienen nuestros modelos en 
«POV» (recordad que aquí solemos 
exportar los modelos a «POV» de tal 
manera que el personaje quede de pie 
sobre el plano X-Z, con los pies a la al- 
tura de Y=0 y con los ojos mirando en 
la dirección -Z. Esta es la orientación 


de nuestro orco y también la del zombi, 
por lo cual no fue preciso reorientar a 
éste en «Imagine»). Hecho esto iremos 
rotando las distintas partes del modelo 
para crear la postura deseada y. al mis- 
mo tiempo, tomaremos nota de los gra- 
dos (visibles en la esquina superior de- 
recha de la pantalla de «Imagine») de 
cada rotación. También hay que recor- 
dar estipular en nuestras notas dónde se 
efectúa la rotación ya que si ésta se lle- 
va a cabo en el hombro, por ejemplo, 
habrá de afectar al brazo completo. 

4) El último paso será crear uno o 
más ficheros plantilla usando el len- 
guaje escénico de «POV» (luego vere- 
mos cómo). En nuestro caso, un pro- 
yecto que describa una escena en la que 
participen regimientos de orcos se 
compone al menos de 3 tipos de fiche- 
ros: uno con la extensión .«POV» que 
describe la escena e invoca a los demás 
archivos, otros que incluyen los valo- 
res de rotación de cada estructura jerár- 
quica del modelo y otro donde se crea 
una jerarquía de uniones que imita a las 
jerarquías del modelo en «Imagine» (o 
a las del modelo usado en su lugar des- 
de este programa). Aunque. por su- 
puesto, esto podría hacerse siguiendo 
otro sistema. 

Otro detalle importante que convie- 
ne no olvidar es que muchas utilidades 
de traducción incluyen en las mallas 
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traducidas una textura similar a la que 
tenía el modelo en el programa donde 
fue creado. Pues bien, si queremos re- 
alizar ciertos trucos como una varia- 
ción aleatoria de color en la piel o 
cambiar los colores de otras partes del 
modelo, lo mejor será eliminar las tex- 
turas traducidas. De esta manera, las 
piezas asumirán la textura indicada en 
orco.inc, la cual puede ser distinta a la 
usada en el modelo-copia anterior, 
puesto que dicha textura puede ser al- 
terada en el fichero de escena. 


Simulación de jerarquías en 
«POV» 

Hemos dicho en las líneas anteriores 
que hay que preparar un archivo que 
establezca un sistema de jerarquías en 
«POV» que imite al que tendría el mis- 
mo modelo en «lmagine». De esta ma- 
nera, podremos hacer girar por ejem- 
plo una mano o un brazo completo, 
según lo que nos propongamos. Quizá 
el lector se extrañe ante esto y se pre- 


gunte si verdaderamente es posible y la z 


respuesta es que sí que lo es, si segui- 
mos unas reglas bien sencillas. 

El modelo completo es una unión o. 
mejor dicho, una unión de uniones, 
donde cada unión establece una agru- 
pación jerárquica de los objetos del 
modelo. Hay una para el brazo dere- 
cho, otra para el izquierdo, etc. Ahora 
veamos un ejemplo extraído del archi- 
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vo orco.inc, donde hemos definido las 


relaciones jerárquicas de nuestro orco: 


En este ejemplo se define la jerar- 
quía para el brazo derecho de nuestro 
orco. Este brazo está compuesto por las 
siguientes piezas: la que define la for- 
ma del hombro y biceps, la del antebra- 
zo y la del puño. Además hay una mu- 
ñequera. y también ha de tenerse en 
cuenta al objeto que el orco siempre tie- 
ne agarrado en el puño derecho (y que 
puede ser la espada, la maza o el estan- 
darte). No hay, pues, piezas aparte para 
el codo o el hombro, lo que significa 
que si hacemos adoptar al brazo ciertas 


posturas algo forzadas comprobaremos 
que las formas del brazo están huecas. 
Lo mismo es vá- 
lido para el resto 
de los miembros 
del modelo. 
Ahora veamos 
cómo funciona 
todo esto. Como 
recordarán los 
«POV»adeptos, 
los objetos en 
«POV» giran en 
torno al eje en 
que se establece 
la rotación y los 
tres ejes, X, Y y 
Z, se cruzan en el 
centro del univer- 
so virtual de 
«POV», en el 
punto <O, 0, 0>. 
Así pues, si por ejemplo creamos una 
esfera centrada en la posición <0, 0, -5> 
y le efectuamos una rotación de 90 gra- 
dos en el eje X, entonces la esfera gira- 
rá en torno a este eje quedando centrada 
en la posición <0, 5, 0>. En cambio, si 
la esfera estuviese centrada, por ejern- 
plo en el punto <-10, O, 0>, entonces se- 
guiría centrada en el mismo punto des- 
pués de la rotación y giraría 90 grados 
sobre sí misma ya que el eje X del uni- 
verso pasa por su centro. Así pues, si 
pretendiésemos hacer girar uno de los 


brazos del orco, no bastaría con indicar 
la operación de rotación. sino que antes 
deberíamos trasladar el brazo entero de 
manera que su eje local comcidiese con 
el centro de coordenadas <0, 0, 0>. Si 
no obrásemos así, el brazo se saldría 
del hombro al efectuarse la rotación. 

Por tanto, y siguiendo con el mismo 
ejemplo, para girar el brazo (o cualquier 
otro objeto) tendremos que seguir tres 
pasos: trasladar el brazo de modo que 
su eje local coincida con el eje del uni- 
verso en torno al cual queremos girar, 
efectuar la rotación y por último aplicar 
al brazo una traslación inversa a la pri- 
mera, de manera que el brazo vuelva a 
quedar encajado en el hombro, 

Todo esto no sería preciso si «POV» 
dispusiera de una instrucción para efec- 
tuar rotaciones en torno a un eje local, 
pero dicha instrucción no existe (o al 
menos es desconocida por nosotros). 
Ahora bien; ¿qué valores daremos a las 
operaciones de traslación que enmarcan 
a cada operación de rotación? 

Evidentemente, los valores que co- 
rrespondan a los puntos donde hemos 
determinado que se hallen los ejes lo- 
cales (recordad que previamente debe- 
remos haber establecido desde el mo- 
delador los ejes locales de todas las 
piezas que puedan girar: en nuestro or- 
co se tomó nota de dichos ejes desde 
«Rhino»). Por ejemplo, hemos decidido 
que el eje local del brazo derecho com- 
pleto de nuestro orco esté en la posición 
<25, -136, -9> (este punto está locali- 
zado, a ojo, en el centro del hombro de 
nuestro modelo). Por tanto, para girar 
el brazo derecho de nuestro orco, he- 
mos escrito las siguientes sentencias: 


translate<25,—136,-—9> 
rotate <rbrazodX, rbrazodY, rbrazodZ> 
translate<—25,136,9> 


Probablemente tanta prolijidad os 
resultará molesta pero hay que asegu- 
rarse de que estos puntos quedan cla- 
ros. Las variables rbrazodX, rbrazodY 
y rbrazodZ son las que especifican la 
cantidad de grados que el brazo va a 
girar en el eje local declarado. Hay va- 
riables con nombres parecidos para ca- 
da articulación y los valores de rota- 
ción para ellas se establecen en otro 
fichero donde, gracias a dichos valo- 
res, se indica la postura que deseamos 
para el orco. Y con esto ya hemos ex- 
plicado cómo giran los miembros del 
cuerpo del orco. 

Ahora pasaremos al siguiente terna: 
¿Cómo podemos simular jerarquías en 
«POV»? 

Echad un nue- 
vo vistazo al lis- 


ñequera derecha). Al final de la unión 
encontraremos las sentencias de tras- 
lación y rotación que afectarán a todo 
el antebrazo permitiéndole girar en 
torno al eje local situado a la altura 
del codo. Esta unión forma parte de 
otra, más exterior, de la que el objeto 
brazod es el otro componente —he- 
mos llamado brazod a esta pieza para 
indicar que su giro afecta al brazo 
completo, aunque el objeto en sí solo 
se refiere a la parte superior del bra- 
zo. Esta zona incluye al hombro y 
acaba a la altura del codo—. Como ya 
imaginaréis, las sentencias de trans- 
formación para esta unión afectan a 
todo el brazo. 


Otra prueba de horda 


cambiando la semilla de rand. 


tado de ejemplo 
anterior. En la 
unión más inter- 
na están los ob- 
jetos manod y 
arma, los cuales 
giraran en torno 
al eje local defi- 
nido para la ma- 
no (si la mano 
derecha del orco 
no empuñase un 
arma no sería preciso declarar una 
unión aquí, y bastaría con incluir las 
transformaciones dentro del objeto 
manod). Luego. siguiendo hacia afue- 
ra, veremos que la unión manod-ar- 
ma forma parte de otra unión com- 
puesta también por los objetos antebd 
(antebrazo derecho) y munned (mu- 


Cuando «POV» vaya a procesar el 


trozo de código del brazo completo, 
comenzará a trabajar con los objetos 
o uniones más internos, efectuando 
primero las rotaciones para la mano 
y el arma asida por ésta (en caso de 
que hayamos dado valores a las va- 
riables de esta zona). Luego, se pro- 
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cesarán las rotaciones para el antebra- 
zo completo y finalmente se ejecuta- 
rán las del brazo entero. Por tanto, 
cuando vayamos a crear un archivo- 
plantilla para otro modelo antropo- 
mórfico. deberemos tener presente 
que lo más sencillo es escribir el con- 


Para la horda de la portada se 
emplearon bastantes regimientos. 


junto desde dentro hacia afuera, co- 
rrespondiendo las piezas de la unión 
más interna a las más extremas del 
miembro tratado. 

Para la pierna derecha, por ejemplo, 
el orden sería pie, pantorrilla-pie, pier- 
na-pantorrilla-pie, siendo el pie el ob- 


jeto más interno de la estruc- 
tura (echad un vistazo a Or- 
co.inc). Todo esto es aplica- 
ble a todas las piezas del 
modelo completo y la Única 
dificultad real estará en de- 
cidir sobre la jerarquía de 
ciertas piezas (y por tanto 
sobre su colocación dentro 
del archivo). 

Es fácil ver que la mano tie- 
ne un nivel jerárquico más in- 
terno que el antebrazo pero... 
¿dónde situaremos la pelvis o 
la cabeza? En el caso de 
nuestro orco hemos ordenado 
esto de manera que hay variiis 
uniones con. el-mismo nivel 
jerárquico. Los brazos (ente- 
ros) y la cabeza. por ejemplo, 
tienen el mismo nivel jerár- 
quico y ambos forman parte 
de la unión que incluye al tó- 
rax y que tiene su eje local-a 
la altura del cinturón del mo- 
delo. Luego hay otra unión 
del mismo nivel que la ante- 
rior y que incluye-a las pier- 
nas (enteras), la falda, la pel- 
vis y el cinturón.-Ambas 
uniones principales están en- 
globadas dentro de la unión 
principal (el cuerpo entero) 
cuyas operaciones afectan a 
todo el conjunto. 

De esta manera, un valor 
dado, por ejemplo, a ran- 
tebdZ hará doblarse el brazo mientras 
que otro dado a rtoraxZ hará doblarse a 
todo el orco de cintura para arriba. Y 
con esto, ya deberíais estar en condi- 
ciones de crear vuestras propias plan- 
tillas jerárquicas para tratar a otros mo- 
delos, ya sean antropomórficos o no. 


Creación de ficheros-postura 

Llamaremos ficheros-postura a los 
archivos donde se dan valores a las va- 
riables de rotación que definen las pos- 
turas de los modelos-copia. Algunos de 
estos ficheros son orcandal, orcombat, 
orcascal, etc. Los números impares 
(cuando los hay) corresponden a pos- 
turas nuevas y los pares a posturas don- 
de se han intercambiado los valores de 
rotación de los brazos y piernas. Estu- 
diadlos y empleadlos como plantilla 
para crear los vuestros propios: 

Una vez que se tiene práctica, pue- 
den crearse posturas directamente 
usando un editor de textos--Si ya-es- 
tá1s pensando en preparar vuestros 
propios modelos. usando es- 
te sistema. tened presente 
que convendrá comprobar 
desde «POV» si cada nueva 
postura es correcta. Para ello 
lo mejor será generar una es- 
cena con al menos tres co- 
pias de la nueva postura y 
darles distintas orientaciones 
con respecto a la cámara. Es- 
to es especialmente reco- 
mendable si hemos estado 
utilizando en «Imagine» otro 
modelo antropomórfico —en 
vez del original— como en el 
presente caso. 

Finalmente comentaremos 


una. última cosa.-Si el lector 
examina la escena del ejército 
orco avanzando y su fichero de genera- 
ción correspondiente (marcha.«POV»). 
se dará cuenta de un curioso detalle: 
la escena sólo utiliza dos posturas, or- 
candal y orcanda2, pero todos los or- 
cos parecen algo diferentes entre sí: 
unos tienen las piernas más levantadas 
o las rodillas más dobladas que otros, 


los hay que adelantan más el brazo, 
etc. Esto se debe sencillamente a que 
hemos incorporado en los dos fiche- 
ros-postura una pequeña variación 
aleatoria para algunas de las jerarquías 
del orco. En efecto, cada vez que el fi- 
chero de escena incluye a uno de los 
archivos orcanda. éstos llaman repeti- 
das veces a un ficherito-función crea- 
do por nosotros donde se da un valor 
aleatorio a la variable “variacion”, la 
cual es luego sumada a las variables 
de rotación. Antes de llamar a este fi- 
cherito de nombre funcal.pvm, hay 
que dar un valor a la vartable-paráme- 
tro “signo”. Normalmente, pondremos 
el valor 255 en esta variable, indican- 


do así que “variacion” puede ser posi- 
tiva O negativa, pero en ciertos casos. 
como por ejemplo en el de una pier- 
na, no nos interesará que la variación 
tenga un sentido determinado, ya que 
entonces podría suceder que el miem- 
bro adoptase una postura anatómica- 
mente indeseada. En estos casos pon- 


dremos a “signo” con el valor +1 o -1 
según el sentido del giro que deseemos 
impedir. Pero esto no es todo. 

Desde el fichero escénico daremos 
también un valor a la variable “vari- 
rand”, la cual es usada en funcal.pvm 
para establecer el rango de variaciones 
que deseamos para “aleatorizar” los 
grados originales de la postura (en 
marcha.pov hemos usado el valor 30. 
Lógicamente cuanto mayor sea este 
valor, mayor será el rango de variacio- 
nes aleatorias para las posturas origi- 
nales). Podemos aplicar este truco a to- 
das nuestras posturas para conseguir 
asi.rehuir un poco la impresión de que 
la escena está compuesta sólo por unas 


Un eXperimehto coh un clradro de lanceros-mesh. 


pocas posturas pero, atención, no po- 
demos usar esta idea siempre. En las 
piernas, sobre todo. corremos el ries- 
go de que éstas se hundan en el suelo 
si permitimos cualquier variación. 
Otra posibilidad de fallo es que uno de 
los brazos del orco se hunda en su pro- 
pio cuerpo así que... ¡cuidado! 
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Una escena cualquiera con 
cientos de actores 

Para visualizar mejor cómo funciona 
todo esto vamos a repasar cómo se ge- 
nera una cualquiera de estas escenas. 
Por ejemplo, en marcha.pov. se especi- 
fica primero la pigmentación “ideal” 
de los orcos. Luego se incluyen todas 
las piezas que pueden aparecer en la 
escena (del cuerpo, las cabezas, las ar- 
mas...). Después, asignamos valores a 
una serie de variables que se emplea- 
rán en ficheros posteriores y luego se 
entra en un bucle anidado con el que 
crearemos un ejército construyendo 
bloques de regimientos. Cada regi- 
miento será creado al invocar al fiche- 
ro regiorc.inc, archivo que utilizará las 
variables anteriores para decidir el an- 
cho del regimiento, su número de filas, 
si llevará un portaestandarte al frente, 
etc. La separación entre regimientos y 
otros detalles también se especificarán 

antes del bucle. 

Una vez en regiorc.inc, 
«POV>» hallará otro do- 
ble bucle con el que 


construirá el regimien- 
to. En cada caso se 
decidirá si el orco 
llevará es- 
cudo, su 
de 
arma, su 


tipo 


inclina- 
ción late- 
ral de ca- 
beza, etc. 
Pero lo más im- 
portante es que 
=según el valor 
de la variable ti- 
poej- se deci- 
dirán cuáles 
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serán los ficheros—postura a emplear. 
Si tipoej vale 1, se creará al ejército 
usando las posturas de los archivos or- 
canda, con lo cual obtendremos un 
ejército marchando. En cambio, si ti- 
poej tiene otro valor, entonces se usará 
el archivo orcombat.inc, el cual creará 
poses de combate. En este último caso 
obtendremos un ejército a punto de en- 
trar en batalla, con nuestros persona- 
jes exhibiéndose en diferentes postu- 
ras de provocación hacia el enemigo. 
Puede parecer mentira el que todos los 
horcos de esta horda hayan sido crea- 
dos tan sólo con este único archivo, pe- 
ro en realidad el truco es muy simple. 

Ante todo se crearon dentro de este 
archivo una serie de poses individua- 
les para los miembros del orco. Hay 
tres posibles colocaciones para el bra- 
zo derecho, dos para el brazo izquier- 
do y una (por ahora) para las piernas. 
Además de esto cada una de estas po- 
sibles colocaciones puede sufrir varia- 
ciones aleatorias dentro de ciertos ran- 
gos calculados para impedir que el 
personaje se atraviese con su propia 
arma (pues, sí, esto sucedió en las 
pruebas iniciales). En resumen: en ca- 
da pasada de orcombat.inc se estable- 
ce aleatoriamente el brazo que va a 
colocarse y las variaciones aleatorias 
correspondientes. El resultado se 
guarda en las variables de rotación 
que más tarde se pasarán a orco.inc 
desde regiorc.inc. 

Todo esto puede parecer muy com- 
plicado al principio pero desengañaos; 
no lo es. Lo realmente importante es 
que entendáis cómo pueden crearse je- 
rarquías simuladas en «POV». Lo de- 
más (la creación de posturas, regimien- 
tos o ejércitos enteros) podéis hacerlo 
si lo preferís de cualquier otra manera. 


Futuras 
escenas 
con mesh 

Visto es- 
to es fácil 
imaginar 
muchas posibles escenas interesantes 
que son posibles con mesh. Con esta 
sentencia ya no sería imposible crear 
ciudades gigantescas o grandes flotas 
espaciales o incluso algo como un 
hormiguero. 

Como mesh puede ser usada en 
conjunción con las llamadas senten- 
cias de programación, las posibilida- 
des son casi ilimitadas. Tan sólo ve- 
mos un problema: aún no hay manera 
de determinar —utilizando colocacio- 
nes aleatorias— sí dos modelos se están 
superponiendo. Esto puede ser bastan- 
te molesto (en las primeras pruebas 
muchos de los orcos se ensartaban 
unos a otros). Contra esto, por ahora, 
la única solución es controlar el espa- 
cio de separación de cada elemento, 
usar bucles de colocación que eviten 
que se trate dos veces una misma zona 


espacial y esperar que haya suerte. 


El Foro del Lector 


Vota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en la segunda página de Pcmenía, o vía e-mail a rendermania.pcmania O hobbypress.es 


Mundos Fascinantes 


Como bien dice Jesús Angel 


Lanza Salcines, aunque 
sepamos muy bien que el 
corazón de nuestro 
ordenador es un frío chip de 
silicio, al otro lado de la 
pantalla de nuestros 
monitores pueden existir 
mundos fascinantes que tan 


sólo esperan a que nosotros 


Probablemente cuando echéis un vistazo a las maravillosas es- 
cenas de Jesús Angel Lanza Salcines os quedaréis tan asom- 


sepa mos h acerlos reali d ad , En brados como yo mismo. Y es que las escenas de este maestro del 
E «Caligari Truespace» no son simples imágenes renderizadas. 
ese otro lado puede haber poesía, Más bien parecen puertas a universos donde se están desarro- 
llando historias como las que cuentan Tolkien, Zelazny. Moor- 
bel leza, fa ntasía e incluso horror. cock y otros maestros de la fantasía. Son escenas soberbias, 
fantásticas, alucinantes, donde las chicas de Jesús no parecen 

Lo que hallemos de pen de rá , como mallas poligonales sino personajes vivos y adorables. 


siempre, de nuestro esfuerzo y de 
la riqueza de nuestro propio 
mundo interior. Y es que algunos 
autores (volviendo a citar a Jesús) 
prefieren considerar a la pantalla 
del ordenador no como frio 
hardware, sino como la puerta a 


un mundo mágico. 
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Seguimos hablando de la obra de Jesu: 

cines. En cuanto a los datos técnicos. poco es lo que pode- 
mos decir sobre la chica. Los datos incluidos por Jesús di- 
cen que Pamela tiene unas 6200 caras (cuesta creerlo, 
¿verdad?). Y tampoco podemos explicar nada sobre el 
propio autor, ya que no nos ha enviado carta alguna. Tan 
sólo contamos con unos interesantes archivos html, donde 
podremos ver escenas y animaciones y leer algunos diver- 
tidos textos relacionados con las imágenes. Podéis encon- 
trar todo esto —junto con otras imágenes que venían en Otra 
carta y que no son referenciadas en los archivos html- en 
el directorio lanza del CD. Amigo Jesús. tu chica es extra- 
ordinaria y podría en mi opinión competir incluso contra 
Kyoko o Rina (otras dos fantásticas chicas 3D que ya vi- 
mos en el número 8 de Rendermanía). Estoy seguro de que 
todos los rendermaníacos desearán tanto volver a verte en 
estas páginas como yo. Hasta entonces dile a Pamela que 
me considere su más ferviente admirador. 


El Foro del Lector 


Como podéis ver en esta página, el orco de Carlos Mont 
Escudero ha progresado mucho. Las manos están muy mejo- 
radas con respecto a las del modelo del número 11 y Carlos ha 
preparado bastantes posturas de este orco creado con el lengua- 
je de «POV». Además, Carlos incluye un brujo (también com- 
pletamente modelado desde «POV») y ha preparado nuevas ar- 
mas para su orco. Bien por ti pov-colega, pero te recomiendo 
que utilices el método que expongo en el presente número. ¡Tar- 
darás menos en crear posturas y grupos de personajes! Por otro 
lado el hermano de Carlos, CESAR, nos ha enviado una peque- 
ña animación de la que espera una crítica que por una vez no 
voy a hacer (la dejaré para tu siguiente animación). En cuanto al 
reto de vuestro clan de orcos, puede ser que decida aceptarlo y 
quizá. quizá, os llevéis una sorpresa. 


Otro par de hermanos: 


nos envían un par de mechs 
creados con «MAX». Am- 
bos hermanos incluyen una 
carta explicando los deta- 
Mles de la construcción de 
sus modelos y las caracte- 
rísticas técnicas de cada 
mech y me piden que diga 
cuál de los dos me ha gus- 
tado más (y además acla- 
ran que no aceptarán un empate). Ambos hermanos aducen las diferentes ventajas de sus mechs y Os- 
car, por ejemplo, afirma que cree al suyo capaz de cualquier misión. ¡Pues bien. no lo creo! Dudo que, 
por ejemplo, fuese capaz de tomar el 1é en el salón de mi casa y por dicha razón le descalifico y duy 
la victoria al de Alberto. Bueno. ahora en serio. os habéis olvidado de especificar qué imagen co- 
rresponde a cada mech aunque creo que me gusta más el blanco ya que su forma me parece mas ori- 
ginal que la del negro. Por supuesto que aceptaré a vuestros modelos para la escena de mechs, que co- 
mo veis se está rerrasando un poco (problemas de converstones). 


ataca de nuevo con dos 
imagenes creadas con «POV». Esta vez se trata 
de una habitación y de una réplica aproximada 
del escenario empleado por U2 para su gira 
“Pop Mart”. Pues hien. ya que pides una crítica 
te diré que la pega principal es que tus imágenes 
podrían haber ganado bastante si hubieras usa- 
do esas sentencias de programación de «POV» 
que aún no has tenido tiempo de aprender. No 
temas: no voy a enviarte un Mech trazado con 
rayos a que te tire de las orejas para que las es- 
tudies, pero sí quiero hacerte notar que si las hubieras usado probablemente tus escenas habrían ga- 
nado mucho con muy poco esfuerzo adicional. Por ejemplo, habrías podido emplear +4while para las 
vallas del estadio o para dar algo de detalle a las gradas del mismo e incluso para el mismo armario. 
Tomo nota de tu sugerencia para la ciudad-portada pero antes habría que especificar algunas reglas de 
construcción ¿no? A fin de cuentas un chalet o un templo romano no pegan en medio de una ciudad 
de rascacielos moderna. Hasta la próxima. 


nos envía una 
imagen de su tanque escorpión que desea 
vender y solicita una opinión. Bueno pues. 
sin ánimo de desanimarte y sin decir en mo- 
do alguno que tu modelo sea malo, he de se- 
ñalarte que incluso los mejores infografistas 
lo tendrían difícil para vender un único mo- 
delo. Además, tu tanque está restringido a 
un campo muy limitado (un buen modelo 
humano lo tendría algo más fácil). Mi con- 
sejo es que, si tienes algo visualizable de ese videojuego estratégico del que hablas. te acerques a al- 
guna casa de soft. Otra posibilidad es trabajar como infografista en alguna casa de juegos. Pero 
mientras buscas. mi consejo es que sigas practicando, ya que sólo cuando se alcanza un nivel de ha- 
bilidad verdaderamente espectacular hay esperanzas de lograr un trabajo en este mundillo. ¡Suerte! 


recibe mi más sentido pésame 
por la disolución de tu grupo y 
también mi más sincera felici- 
tación por tu estupendo Mech. 
Me alegra tu intención de par- 
ticipar en la convocatoria de la 
portada sobre Mechs (que co- 
mo ves. se va a retrasar un po- 
co) pero lo que dices es bien 
cierto: tu mech emplea mu- 
chas texturas que yo habría de 
aplicar pieza a pieza desde 
«POV» ya que no conozco 
ningún conversor que “traduz- 
ca” también la aplicación de 
las texturas. ¿Qué hacer? Aún 
no lo sé. En cuanto a tu suge- 
rencia para el collage, desde 
luego es lo que menos trabajo 
me costaría pero la verdad es 
que prefiero preparar una por- 
tada normal, aunque no voy a 
descartar tu idea. 

Por último quiero felicita- 
ros ati y a David Lozano Lu- 
cas por vuestra revista electró- 
nica “Euro 3d Design” (leed 
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los detalles en la carta de Ben- 
yi). Para ella, como dice 
Spock; ¡Larga y próspera vida! 


VOLCADO DE ANIMACIONES > PRODUCCION Y POSTPRODUCCIÓN DIGITAL DE VIDEO 


¿Te gustan tus trabajos 2D/3D? 


Entonces, ¿por qué los 
terminas en formato AVI, FLI, 
o con tarjetas MPEG de baja 
calidad, cuando puedes 
obtener resultados 
verdaderamente 
profesionales a un coste 
razonable? 


Si eres usuario de AutoCAD, 3D Studio, Animator Pro, LightWave, 
POVRay, etc. y quieres tener tus propias animaciones volcadas a 
vídeo en calidad Broadcast Betacam, así como toda una serie de 
servicios adicionales, llámanos y te informaremos. 


¿Te imaginas? 


Poder ver en video cualquiera 
de tus animaciones. 


¡Increible! 
A 
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